(19) 



(12) 



(43) Date of publication: 

07.06.2000 Bulletin 2000/23 

(21) Application number: 99123955.9 

(22) Date of filing: 06.12.1999 



Europdisches Pa tent a mt 
European Patent Office 
Office europ^endes brevets (11) EP 1 006 471 A2 

EUROPEAN PATENT APPLICATION 

(51) Int. Cl. 7 : G06F 17/60 



(84) Designated Contracting States: 

AT BE CH CY DE DK ES Fl FR GB GR IE IT U LU 
MCNLPTSE 

Designated Extension States: 
AL LT LV MK RO SI 



(30) Priority: 



04.12.1998 US 111032 
04.12.1998 US 111030 
04.12.1998 US 111031 



(71) Applicant: 

CITIBANK AKTIENGESELLSCHAFT 
60311 Frankfurt (DE) 

(72) Inventors: 

• Rayner, Peter E. 

Westf teld, NJ 07090 (US) 

• Brooks, Elizabeth 

Mawnan Smith, Falmouth Cornwall TR11 5JW 
(GB) 

• Irwin, Fred 

60599 Frankfurt (DE) 



• Johnson, Mark 

Greather Manchester WN2 2SN (GB) 

• Lieven, Andreas T. 
65779 Kelkhelm (DE) 

• Potter, Neil 

Westf ield, NJ 07090 (US) 

• Raschdorf, Andreas 
61267 New Anspach (US) 

• Torremante, Marie 
65187 Wiesbaden (DE) 

• Licci, Christine 
63456 Hanau (DE) 

• Pfundt, Dieter 
65719 Hofheim (DE) 

(74) Representative: 
Beetz & Partner 
PatentanwStte 
Steinsdorfstrasse 10 
80538 MQnchen (DE) 



(54) Computer system for data management and method for operation of the system 



(57) An automated trading system makes use of 
various components, such as one or more transaction 
servers (6. 202) and one or more rate servers (8, 204) 
and a number of terminals (2, 210; 4, 102, 104). A 
request for a proposed transaction for a user (12, 116, 
208) is entered at either a user's terminal (2, 210) or a 
sales trader's terminal (4, 102, 104) and sent to a trans- 
action server (6, 202) coupled to a rate server (8, 204). 
If a first predefined condition for generating an executa- 
ble rate quote is identified, an executable rate quote is 
generated by the rate server (8, 204) and sent back to 
the user's (2, 210) or sales trader's terminal (4, 102, 
104) for the user (12, 116, 208). Otherwise, if a second 
predefined condition for a category trader's rate quote is 
identified, a request for the category trader's rate quote 
is sent by the transaction server (6, 202) to one or more 
category trader's terminals, prompting entry of a cate- 
gory trader's rate quote by one or more of the category 
traders, which is likewise sent back to the user's (2, 210) 
or sales trader's terminal (4, 102, 104) for the user (12, 
116, 208). If a request for execution is entered at the 
user's (2, 210) or sales trader's terminal (4, 102, 104) 



within a predetermined period of time, the transaction 
server (6, 202) hands off the request for execution to a 
hand-off server (7, 108, 206), which executes the trans- 
action for the user (12, 1 16, 208). 
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Description 

Cross Reference to Related Applications 

[0001] This application is a continuation-in-part of 
U.S. Serial No. 08/836,713, filed May 13, 1997, which 
claims priority to applicants* PCT application no. 
PCT/EP96/03972, filed September 10. 1996, and which 
claims priority to applicants' EPO application no. 
951 14467.4, filed September 14, 1995. This application 
claims priority to applicants' co-pending applications 
Serial No. 60/111,030 filed December 4, 1998; Serial 
No. 60/111,031 filed December 4, 1998; and Serial No 
60/1 1 1 ,032 filed December 4, 1998. 

Held of the Invention 

[0002] The present invention relates to a computer 
system for data management and method for operation 
of the system, and more particularly to an automated 
warrant trading system. 

Background of the Invention 

[0003] In the past, the trading of warrants was time 
consuming and cost intensive, because it was neces- 
sary for a customer in a financial institution, such as a 
bank, to search by telephone or in publications to locate 
the best warrant for a consumer. If the consumer wished 
to purchase warrants, it was necessary for the con- 
sumer to first contact his or her local bank which could 
process the order through a stock exchange or by plac- 
ing a call to a warrant market maker. Since an on-line 
information and trading system about traded warrants 
with executable prices did not exist, the customer in the 
local bank was not able to provide the consumer with 
actual on-line information. Hence, there existed a time 
differential between the placing of a buy/sell order by 
the customer and its implementation, resulting in a risk 
of exchange and/or price fluctuations during that time 
difference. 

[0004] It was often the case that the implementation 
of the buy/sell order was based on a limit oriented on 
the rates of the previous day, since the order could not 
be implemented on the same day. The reasons for the 
time delay were either that the order was placed a 
number of hours before it was executed at the stock 
exchange or that the trading room telephones of the 
market maker were often busy during hectic market 
times. Therefore, local banks often placed blind orders 
at unknown prices for consumers and did not receive 
immediate deal confirmations. 

[0005] The invention disclosed in co-pending U.S. 
Pat. Application Ser. No. 08/836.713 (referred to herein 
as "the CATS-OS system" or "the existing CATS-OS 
system" and incorporated herein by this reference) 
addresses those problems and provides a computer 
system for data management and a method for operat- 



ing the system for the bank, which realizes a data man- 
agement providing instantaneous data with an improved 
accuracy and a reduced error probability when process- 
ing data transactions, combined with a high level of 

5 security. The existing CATS-OS system includes use of 
a client-server architecture, which has a number of 
servers, such as a transaction server, a rate server, a 
hand-off server, a credit server, and a security server. In 
a typical interaction with the CATS-OS system, the cus- 

10 tomer or other user of the system connects to the sys- 
tem and is authenticated by a security manager, which 
allows the user certain privileges depending on the level 
of user, such as customer, trader, and administrator lev- 
els. 

15 [0006] In the existing CATS-OS system, a customer 
normally is allowed to view rates, execute transactions, 
view those transactions, print reports against transac- 
tions conducted, and view positions. A trader is allowed 
to manually input rates if desired, although this not a 

20 normal trader function. Normal trader functions include 
maintaining instruments as new instruments become 
available and old instruments expire, generally main- 
taining the system, maintaining volumes, maintaining 
the credits, and maintaining the users themselves. The 

25 main rate and sales information is input automatically 
from customer systems. Customers typically have vari- 
ous systems that calculate the prices of warrants. The 
CATS-OS system essentially receives all of the rates 
information that comes from customer systems, which 

30 may be three or four million updates a day, inputs this 
information into a separate rate server arid then holds 
this information so that it is available for the customers 
to deal against. 

[0007] Currently, the CATS-OS system, which pri- 

35 marily deals with warrants and equities, functions on a 
standing price basis, in which the host bank for the sys- 
tem issues a price that the bank guarantees for a cer- 
tain number of seconds. This guarantee allows the 
users of the CATS-OS system to deal at the price 

40 issued. However, in order to limit the risk to the host 
bank, the host bank typically only authorizes deals up to 
a certain size at the standing price. Thus, a problem 
with the existing CATS-OS system is that users may 
need to perform deals that exceed the host bank's 

45 allowable deal size. 

[0008] In addition, the existing CATS-OS system 
requires a certain amount of technology and equipment 
to be available at the customer's or other user's site. 
This technology and equipment can include a personal 

so computer (PC) and the capability to communicate data. 
Not all customers or other potential users of the CATS- 
OS system wish to have these capabilities installed, and 
instead prefer to deal with warrant trading on the tele- 
phone by directly speaking to a trader. This preference 

55 directly conflicts with the purpose of the CATS-OS sys- 
tem, which is intended to avoid the situation of custom- 
ers directly speaking to traders for what are typically 
smaller sized trades. 
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[0009] Further, while the existing CATS-OS system 
provides an effective automated electronic trading tool 
for bank customers and consumers for a single bank, 
the system displays the process of only one bank. The 
customers are primarily brokers, so the bank is often 5 
unaware of the identity of the actual consumer. Cur- 
rently, it is not possible, for example, for a plurality of 
banks to add prices to the CATS-OS system in order to 
allow brokers to buy and sell warrants of other banks for 
consumers while deeding with only a single system. 

Summary of the Invention 

[0010] It is a feature and advantage of the present 
invention to provide an automated trading system and 
method which allows deals to be consummated that 
exceed limits imposed, for example, by the host bank, 
as well as in other circumstances in which a rate may 
not be available. 

[0011] It is a further feature and advantage of the 
present invention to provide an automated trading sys- 
tem and method which allows a trader to respond to a 
request for a quote and to provide a proposed price 
against which a user can trade. 

[0012] It is another feature and advantage of the 
present invention to provide an automated trading sys- 
tem and method which allows a special type of trader, 
referred to as a sales trader, to deal on behalf of 
selected customers within the trading system, without 
necessarily knowing the price of particular warrants and 
without setting their own prices. 
[0013] It is an additional feature and advantage of 
the present invention to provide an automated trading 
system and method which affords all the advantages of 
the system, such as reduced error rates, without the 
expense associated with actually installing the system. 
[0014] It is another feature and advantage of the 
present invention to provide an automated trading sys- 
tem and method which enables selected customers to 
deal over the telephone and avoids the necessity for 
such customers to install the system. 
[0015] It is a further feature and advantage of the 
present invention to provide an automated trading sys- 
tem and method which enables full warrant trading 
capabilities without the expense of highly paid profes- 
sional traders. 

[0016] It is an additional feature and advantage of 
the present invention to provide an automated trading 
system and method which enables users to easily buy 
and sell warrants from a plurality of banks and market 
makers. 

[0017] It is a further feature and advantage of the 
present invention to provide an automated trading sys- 
tem and method that avoids the need for users of the 
system of one bank who access the system by dial-up 
having to disconnect and redial with another bank. 
[0018] tt is another feature and advantage of the 
present invention to provide an automated trading sys- 



tem and method which avoids the necessity for a user 
having to log in separately to a plurality of systems. 
[0019] It is an add tional feature and advantage of 
the present invention to provide an automated trading 
system and method that avoids integrating the system 
to the extent that the system may be considered and 
regulated as a stock exchange. 
[0020] It is another feature and advantage of the 
present invention to provide an automated trading sys- 
tem and method that maintains segregation between 
price makers. 

[0021] To achieve the stated and other features, 
advantages and objects, an embodiment of the present 
invention provides an automated system and method 
for warrant trading which includes various aspects, such 
as a request for quote aspect, a sales trader aspect, 
and a multi-bank aspect. The method and system for an 
embodiment of the present invention makes use, for 
example, of various servers, such as a transaction 
server, a rate server, a hand-off server, a credit server, 
and a security server. 

[0022] The request for quote aspect for an embodi- 
ment of the present invention makes use in particular, 
for example, of a user terminal, category trader termi- 
nals, the transaction server, the rate server, and a mail 
server. The sales trader aspect for an embodiment of 
the present invention makes use in particular, for exam- 
ple, of one or more sales trader terminals, the transac- 
tion server, the credit server, the hand-off server, and 
the credit server. The multi-bank aspect for an embodi- 
ment of the present invention makes use in particular, 
for example, of the user terminal, as well as the transac- 
tion servers, rate servers, and hand-off servers of a plu- 
rality of independently maintained and segregated 
trading systems. 

[0023] In an embodiment of the present invention, a 
request for the user for a proposed financial transaction, 
such as a warrants trade, is received at a terminal, such 
as the user terminal or the sales trader terminal. The 
request can be received at the user terminal by the user 
directly inputting the request at the user terminal. Alter- 
natively, the request is communicated, for example, by 
telephone, fax or e-mail by the user to a sales trader and 
is received at the sales trader terminal by the sales 
trader inputting the request for the user at the sales 
trader terminal. 

[0024] In turn, in an embodiment of the present 
invention, the request is received from the terminal by a 
transaction server coupled to the terminal and by a rate 
server coupled to the transaction server. In the multi- 
bank aspect, the request is received from the terminal 
by the transaction servers of each of the plurality of 
independently maintained and segregated trading sys- 
tems coupled to the terminal and by the corresponding 
rate server coupled to the transaction servers of each of 
the trading systems. 

[0025] In an embodiment of the present invention, a 
rate quote is generated by the system, which consists of 
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either an executable rate quote or a category trader's 
rate quote for the proposed financial transaction. The 
executable rate quote is automatically generated by the 
rate server, if a first predefined concfition for generating 
the executable rate quote is identified by the transaction 5 
server or the rate server coupled to the transaction 
server. In the multi-bank aspect, the executable rate 
quote is automatically generated by the rate server of at 
least one of the plurality of trading systems coupled to 
the corresponding transaction server of the particular 10 
trading system, if the first predefined condition for gen- 
erating the executable rate quote is identified by either 
the rate server or the transaction server of the particular 
trading system. 

[0026] In an embodiment of the present invention, 15 
the first predefined condition for automatically generat- 
ing the executable rate quote exists if a predefined 
cause for rejection of the proposed transaction, such as 
the transaction counterparty is suspended, the pro- 
posed transaction system is suspended, the proposed 20 
transaction instrument is suspended, the proposed 
transaction rate is suspended, the proposed transaction 
exceeds the available volume, or the proposed transac- 
tion amount exceeds a predefined limit, is not identified 
by either the transaction server or the rate server. 25 
[0027] In an embodiment of the present invention, if 
the first predefined condition for automatically generat- 
ing the executable rate quote is not identified, then the 
category traders rate quote is generated if a second 
predefined condition for generating the category 30 
trader's rate quote is identified. The second predefined 
condition for generating the category trader's rate quote 
exists if one or more of the predefined causes for rejec- 
tion of the proposed financial transaction is identified by 
either or both of the transaction server or the rate server 35 
coupled to the transaction server and if a predetermined 
selling of a request for quote parameter corresponding 
to the one or more identified cause or causes for rejec- 
tion is likewise confirmed by one or both of the transac- 
tion server or the rate server. 40 
[0028] In an embodiment of the present invention, if 
the second predefined condition for generating a cate- 
gory trader's rate quote is identified, the transaction 
server automatically generates a request for a category 
trader's rate quote, which is automatically communi- 45 
cated by the transaction server via a mail server to one 
or more category trader's terminals. One or more of the 
category traders is prompted by a display on the cate- 
gory trader's terminal for entry of the category trader's 
rate quote, and at least one of the category traders can so 
then enter the category trader's rate quote at the cate- 
gory trader's terminal, which is communicated by the 
trader's terminal to the transaction server. 
[0029] In an embodiment of the present invention, 
the transaction server sends either the executable rate 55 
quote or the category trader's rate quote to the user's 
terminal, or in the sales trader aspect, to the sales 
trader terminal for the user, where the rate quote is 



automatically displayed for the user. At the same time, a 
system counter is automatically set for a predetermined 
period of time, which holds the generated rate quote for 
the user for the predetermined time period and. in 
effect, guarantees the rate quote for the predetermined 
time period for the user. 

[0030] If a request for execution of the proposed 
transaction for the user is received at the user's termi- 
nal, or in the sales trader aspect, at the sales trader's 
terminal, within the predetermined period of time, the 
request for execution is automatically sent to the trans- 
action server coupled to the terminal. In the multi-bank 
aspect, the request for execution is automatically sent to 
the transaction server of one of the plurality of trading 
systems. In either case, the request for execution is 
automatically handed off to a hand-off server coupled to 
the transaction server, and the hand-off server automat- 
ically executes the proposed transaction for the user. 
[0031] Additional objects, advantages and novel 
features of the invention will be set forth in part in the 
description which follows, and in part will become more 
apparent to those skilled in the art upon examination of 
the following, or may be learned by practice of the inven- 
tion. 

Brief Description of the Drawings 
[0032] 

Fig. 1 is a schematic diagram which illustrates an 
example overview of key components and the flow 
of information between the key components of a 
request for quote aspect of an embodiment of the 
present invention; 

Fig. 2 is a sample category maintenance screen for 
the request for quote aspect of an embodiment of 
the present invention; 

Fig. 3 shows a sample deal entry screen for the 
request for quote aspect of an embodiment of the 
present invention; 

Fig. 4 shows a sample message box for the request 
for quote aspect of an embodiment of the present 
invention; 

Fig. 5 shows a sample trade details screen for the 
request for quote aspect of an embodiment of the 
present invention; 

Fig. 6 is a flow chart which illustrates an example of 
the process of the customer requesting a rate in the 
request of quote aspect of an embodiment of the 
present invention; 

Fig. 7 is a flow chart which illustrates an example of 
the request for quote notification process for the 
request for quote aspect of an embodiment of the 
present invention; 

Fig. 8 is a schematic diagram which illustrates an 
overview example of key components and the flow 
of information between the key components in a 
sales trader aspect of an embodiment of the 
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present invention; 

Fig. 9 is a schematic diagram which illustrates an 
example overview of databases for the sales trader 
aspect of an embodiment of the present invention; 
Fig. 10 is a schematic diagram which amplifies and 
provides further detail regarding the sample data- 
base overview shown in Fig. 9; 
Fig. 1 1 shows a sample deal entry screen for the 
sales trader aspect of an embodiment of the 
present invention; 

Fig. 12 shows a sample transaction screen for the 
sales trader aspect of an embodiment of the 
present invention; 

Fig. 13 shows a sample branch maintenance 
screen for the sales trader aspect of an embodi- 
ment of the present invention; 
Fig. 14 shows a sample customer maintenance 
screen for the sales trader aspect of an embodi- 
ment of the present invention; 
Fig. 1 5 shows a sample trade details screen for the 
sales trader aspect of an embodiment of the 
present invention; 

Fig. 16 is a flow chart which illustrates an example 
of the sales trader transaction process for the sales 
trader aspect of an embodiment of the present 
invention; 

Fig. 17 is a schematic diagram which illustrates an 
overview example of Key components and the flow 
of information between the key components for a 
multi-bank aspect of an embodiment of the present 
invention; and 

Fig. 18 is a flow chart which illustrates an example 
of the process of a customer transaction in the 
multi-bank aspect of an embodiment of the present 
invention. 

Detailed Description 

[0033] Referring now in detail to an embodiment of 
the invention, an example of which is illustrated in the 
accompanying drawings, a request for quote aspect of 
an embodiment of the present invention provides an 
automated system and method for warrant trading 
which allows deals to be consummated that exceed the 
limits allowed by the host bank and in other circum- 
stances in which a rate may not be available. To accom- 
plish this function, an embodiment of the present 
invention allows a trader to respond to a request for a 
quote and to provide a proposed price against which the 
user can trade. The system and method of an embodi- 
ment of the present invention performs the request for 
quote function, which was not previously possible, in 
connection with the existing CATS-OS system. 
[0034] Fig. 1 is a schematic diagram which illus- 
trates an example overview of key components and the 
flow of information between key components of the 
request for quote aspect for and embodiment of the 
present invention. The request for quote aspect makes 



use, for example, of a graphical user interface (GUI), 
including a customer GUI 2 and a trader GUI 4. The 
request for quote aspect also utilizes a warrants trans- 
action server (WTS) 6, a warrants rate server (WRS) 8, 

5 and a mail server (MAI) 10. The request for quote 
aspect is activated when a user, such as a customer 12 
at the customer GUI 2, attempts to conduct a deal as 
normal within the CATS-OS system, but is prevented for 
some reason specific to the existing CATS-OS system, 

w such as the maximum transaction size being exceeded. 
A message regarding the attempted deal is routed to a 
trader 14 at the trader GUI 4. The trader 14 views infor- 
mation about the deal, which allows the trader 14 to 
monitor the deal and to input a proposed price manually, 

is based on criteria provided in the customer's attempt. 
The manually input information is then transmitted to 
the customer 12, who has the opportunity to accept or 
decline the proposed deal. 

[0035] Thus, the request for quote aspect for an 
20 embodiment of the present invention includes essen- 
tially an electronically messaged conversation between 
the customer 12 at the customer GUI 2 and the trader 
14 at the trader GUI 4, providing an extension of the 
existing CATS-OS system under certain circumstances, 
25 a principle one of which is that the attempted deal is 
larger than the host bank is willing to handle at the 
standing price. To accomplish this electronic messag- 
ing, an embodiment of the present invention provides 
additional messaging capability to existing CATS-OS 
30 system messages. In particular, an embodiment of the 
present invention includes a system and method for pro- 
viding messages directly between the customer GU1 12 
and the trader GUI 4. The trader 14 at the trader GUI 4 
views a pop-up message when the customer 12 at the 
35 customer GUI 2 wishes to perform a rate that would not 
otherwise be allowed, and the trader 14 then responds 
accordingly, for example, by inputting a proposed price. 
[0036] The request for quote aspect for an embodi- 
ment of the present invention improves the usability of 
40 the existing CATS-OS system by allowing the trader 14 
to quote rates for all instruments for which the trader 14 
is responsible. The trader 14 is kept permanently 
informed of the warrant transactions that are being 
rejected, and the trader 14 is given the power to over- 
45 ride the rejected transactions. The request for quote 
mechanism is useful where the CATS-OS system is 
unable to quote an executable rate automatically. It is 
also useful for executing transactions that would other- 
wise be rejected due to certain request for quote trig- 
so gers or parameters. For every warrant deal transaction 
that would otherwise be rejected, an embodiment of the 
present invention makes it possible for the trader 14 to 
override the request for quote triggers. The trader 14 
also has the ability to quote a rate to the customer 12 for 
55 the above circumstances. These request for quote noti- 
fications go only to the traders who are responsible for 
the instruments specified in the warrants transactions. 
[0037] Fig. 2 is a sample category maintenance 
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screen 1 6 for the request for quote aspect of an embod- 
iment of the present invention. Every instrument 
belongs to a category. For every category, parameters 
are set up which indicate when a request for quote 
should be triggered. These categories include, for 5 
example, the deal amount exceeds a maximum allowed 
18; the deal amount exceeds the available volume 20; 
the rate is suspended 22 due to sanity, spread, or time- 
out; the instrument is suspended 24; the counterparty is 
suspended 26; or the system is suspended 28. The 7 
default setting is all of the request for quote triggers 
switched on. For new categories added, the QUI dis- 
plays the default settings. The trader 1 4 is able to switch 
off any or all of the request for quote triggers for a given 
category. Hence, for every warrants transaction, the 7) 
WTS 6 only triggers the request for quote based on 
what the set-up is for that instrument category. 
[0038] In an embodiment of the present invention, 
the default setting is such that if any or all of the request 
for quote trigger situations arise, then the WTS 6 trig- & 
gers a request for quote to the category traders. All of 
the reasons resulting in the request for quote are 
shown. If all of the request for quote (RFQ) trigger 
parameters are switched off except one. such as the 
instrument is suspended 24, then any warrants transac- 2t 
tion is rejected in all the trigger circumstances, except 
when the instrument is suspended. If none of the RFQ 
triggers are switched on. then any of the trigger circum- 
stances result in the WTS 6 transaction being rejected. 
All traders and system administrators, with the privilege 30 
to maintain instruments, automatically have the access 
rights to maintain categories and RFQ trigger parame- 
ters. 

[0039] Fig. 3 shows a sample deal entry screen 30 
for the request for quote aspect of an embodiment of the 35 
present invention. The customer 12 enters the instru- 
ment identification 32 and volume 34 and indicates 
whether the customer 12 wishes to buy or sell the war- 
rant. The GUI validates the details and transmits the 
price quote request to the WTS 6. For every transaction. 40 
the WTS 6 checks whether any RFQ parameters are 
switched on or not. For the instrument specified by the 
customer 12 in the warrants transaction, the WTS 6 
gets the RFQ parameters from the WRS 8. The WTS 6 
performs various checks, such as checking if the coun- 45 
terparty or system is suspended. If the relevant RFQ 
parameters, such as counterparty suspended 26 or sys- 
tem suspended 28 are set and the counterparty or sys- 
tem is suspended, then the WTS 6 acknowledges that a 
request for quote is required for the transaction. Other- so 
wise, the transaction is rejected with the appropriate 
message displayed on the screen of the customer GUI 
2. If all is well, the WTS 6 passes the rate request to the 
WRS 8. 

[0040] In the request for quote aspect of an embod- 55 
iment of the present invention, the WRS 8 performs var- 
ious checks, such as instrument suspensions, rate 
suspensions due to sanity, spread or time-out. If any of 



these are true, and the relevant RFQ parameters, such 
as instrument suspended 24 or rate suspended 22, are 
set, then the WRS 8 is unable to quote a rate. The WRS 
8 then acknowledges that a request for quote is needed 
and gives the reasons for it and passes these to the 
WTS 6. Otherwise, if the instrument or rate is sus- 
pended and the relevant RFQ parameters, such as 
instrument suspended 24 or rate suspended 22, are 
switched oft the transaction is rejected, and the GUI dis- 
< plays an appropriate message on the screen. In the 
existing CATS-OS system, the WRS 8 checks if the deal 
size exceeds available volume when the customer 12 
executes a warrants transaction. However, in the 
request for quote aspect for an embodiment of the 
present invention, the WRS 8 does this check when the 
customer 12 requests a price quote. The WRS 8 checks 
if the deal amount exceeds the available volume. If the 
deal amount is greater than the available volume, and 
the relevant RFQ parameter, namely exceeds available 
volume 20, is set, then the WRS 8 acknowledges that a 
request for quote is needed, and this is sent to the WTS 
6. Otherwise, if the WRS 8 is able to quote an executa- 
ble rate automatically, the WRS 8 sends the quote to the 
WTS 6. 

[0041 ] In the request for quote aspect of an embod- 
iment of the present invention, the WTS 6 checks if the 
deal amount, determined by the buy or sell rate times 
the volume, exceeds the maximum transaction lirrtt 
allowed. In the existing CATS-OS system, this check is 
done at deal execution time. In the request for quote 
aspect for an embodiment of the present invention, it is 
done when the customer 12 requests a price quote. If 
the amount exceeds the maximum limit, and the rele- 
vant request for quote parameter, namely exceeds max- 
imum 18. is set. then the WTS 6 acknowledges that a 
request for quote is required. Otherwise, the transaction 
is rejected. If all is well, and the WRS 8 quotes an exe- 
cutable rate, the executable rate is passed to the cus- 
tomer GUI 2 for the customer 12 to see. If the customer 
12 executes the deal within a certain time period by 
pressing the "Buy" button 36 on the deal entry screen 
30, the deal is executed. Alternatively, the customer 12 
can press the "Cancel" button 38 on the deal entry 
screen 30, in which case the transaction is deleted. If a 
time-out occurs, then the customer 12 is either able to 
re-request a rate, by pressing the "Re-request" button 
40 on the deal entry screen 30, or cancel the deal. Re- 
requesting a deal results in the previous transaction 
being deleted and a new one being entered in the trans- 
actions database of the WTS 6. Otherwise, the transac- 
tion remains unexecuted. 

[0042] In the request for quote aspect of an embod- 
iment of the present invention, if a request for quote is 
necessary, the WTS 6 informs the customer GUI 2. 
including all the reasons for it The customer GUI 2 
informs the customer 12 with a message, such as "Wait- 
ing for response from trader." The "Buy" button 36 is dis- 
abled, because the customer 12 cannot execute the 
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deal until the dealer 14 accepts the indicated rate or 
provides a deal rate. The "Re-request" button 40 and 
"Cancel" button 38 are enabled to allow the customer 1 2 
to re-request a rate or delete the transaction. If the 
response of the trader 1 4 is not received within a certain 5 
time period, the request for quote times out, and the 
customer GUI 2 informs the customer 12 with a mes- 
sage, such as "Sorry, no response from trader." 
[0043] In the request for quote aspect of an embod- 
iment of the present invention, a category trader 14 can 10 
respond to the request for quote by accepting the rate 
quoted by the WRS 4, by quoting a dealer's rate or by 
rejecting the transaction. The trader's request for quote 
response is sent by the WTS 6 to the customer GUI 2. If 
the category trader 14 rejects the request for quote, the is 
customer GUI 2 validates that the details displayed on 
the screen are the same as the request for quote. If so, 
the customer GUI 2 displays a message, such as "RFQ 
has been refused," and the "Re-request" button 40 and 
"Cancer button 38 are enabled to allow the customer 12 20 
to re-request a rate or delete the transaction. If the cat- 
egory trader 14 accepts the request for quote, the cus- 
tomer GUI 2 validates that the trader's response to a 
request for quote relates to the transaction details dis- 
played on the screen. If so, the customer GUI 2 then dis- 25 
plays the dealer's rate and awaits the customer's 
response. The customer 12 can reject the deal rate by 
pressing the "Cancel" button 38, in which case the 
transaction is deleted from the transaction database of 
the WTS 6. The customer 12 can accept the dealer's 30 
rate by pressing the "Buy" button 36, and the transac- 
tion is then executed. 

[0044] Fig. 4 shows a sample message box 44 for 
the request tor quote aspect of an embodiment of the 
present invention. When a request for quote trigger 35 
occurs, the WIS 6 sends a notification message to the 
MAI 10. The MA1 10 then sends a message to the on- 
line category traders alerting them of a request for 
quote. The category traders are able to see these sys- 
tem generated messages in the request for quote mes- ao 
sage box 44 or when they read their mail. However, if 
none of the category traders are logged on, then the 
MAI 10 sends the request for quote messages to all 
traders belonging to the default trader category. The 
default category traders are able to see the request for 45 
quote messages in the request for quote message box 
44 or when they next read their mail. 
[0045] In the request for quote aspect of an embod- 
iment of the present invention, every time a request for 
quote is triggered, if a trader in the same category is so 
logged on, then the trader 14 is notified by a message in 
the status bar on the screen of the trader GUI 4 advising 
of an incoming message with time, text, and system 
name, such as "Incoming message: 10:47:52 *815725 
request for quote RATES". If none of the category trad- ss 
ers are logged on, then those default trader category 
members logged on receive the message. The trader 14 
is able to select a message from the request for quote 



message box 44 and double click to provide a dealer's 
rate for the warrants transaction that is awaiting a rate 
quotation. The current transaction details then appear in 
the screen. Once the dealer 14 accepts or rejects the 
transaction, a mail message is added in the request for 
quote message box 44 notifying the category traders of 
the change in request for quote status. In addition, the 
trader GUI 4 displays the message in the status bar to 
alert the category traders of an incoming message with 
time, text, and system name, such as "Incoming mes- 
sage: 10:47:52 *815725 request for quote accepted 
RATES" or "Incoming message: 10:47:52 *815725 
request for quote rejected RATES." If none of the cate- 
gory traders are logged on, then those default trader 
category members logged on receive the message. 
[0046] Fig. 5 shows a sample trade details screen 
46 for the request for quote aspect of an embodiment of 
the present invention. When a request for quote is 
selected, the trader GUI 4 gets the transaction details 
from the WTS 6. The transaction may not exist because 
the customer 12 may have decided not to wait for a 
trader's response and cancelled the deal. If this is the 
case, the trader GUI 4 displays a message, such as 
"Sorry, request for rates has been cancelled." Other- 
wise, the transaction details are displayed on the trade 
details screen 46 including the reason for the request for 
quote. The trader 14 can accept any rate quoted by the 
WRS 8. enter a dealer's rate, or reject the transaction. If 
the dealer 14 presses the "Accept" button 48 on the 
trade details screen 46, the request for quote status In 
the transaction database of the WTS 6 is updated 
accordingly. Similarly, the request for quote status is 
updated if the dealer 14 presses the "Reject" button 50 
on the trade details screen 46. The result is transmitted 
from the trader GUI 14 to the WTS 6, and the result is 
sent on to the customer 12 at the customer GUI 2. The 
WTS 6 also broadcasts the updated request for quote 
status, via the MA1 1 0, to all of the on-line category trad- 
ers. If the trader 14 rejects the request for quote, the 
customer GUI 2 displays a refusal message and ena- 
bles the "Re-request" button 40 and "Cancel" button 38 
on the deal entry screen 30. If the trader 14 accepts the 
request for quote, the customer GUI 2 displays the 
dealer's rate. The customer 12 can reject the deal rate 
by pressing the "Cancel" button 38 or accept the deal 
rate by pressing the "Buy" button 36, and the transac- 
tion is executed. 

[0047] Fig. 6 is a flow chart which illustrates an 
example of the process of the customer 12 requesting a 
rate in the request for quote aspect of an embodiment of 
the present invention. At S1, the customer 12 logs on 
the customer GUI 2 and enters an instrument identifica- 
tion 32, a volume 34, and indicates whether to buy or 
sell 36. At S2. the customer GUI 2 validates the details 
and sends the rate request to the WTS 6. At S3, the 
WTS 6 receives the rate request and checks if the coun- 
terparty or system is suspended. If not, the WTS 6 
sends the rate request to the WRS 8. If the counterparty 



7 



BNSDOCID: <EP 1006471A2 |„> 



13 



EP 1 006 471 A2 



14 



or system is suspended, the WTS 6 checks if the rele- 
vant RFQ parameters 26, 28 are set. If not, the WTS 6 
sends a rejection message to the customer GUI 2. If the 
relevant RFQ parameters 26, 28 are set, the WTS 6 
sends the rate request to the WRS 8. 
[0048] Referring further to Fig. 6, at S4, the WRS 8 
receives the rate request and checks if the instrument or 
rate is suspended. If not, the WRS 8 checks if the deal 
size exceeds available volume. If the instrument or rate 
is suspended, the WRS 8 checks if the relevant RFQ 
parameters 24, 22 set. If not, the WRS 8 sends a rejec- 
tion message to the WTS 6 lor the customer GUI 2. If 
the relevant RFQ parameters 24, 22 are set, the WRS 8 
checks if the deal size exceeds available volume. If the 
deal size does not exceed available volume, the WRS 8 
sends an executable rate to the WTS 6. If the deal size 
exceeds available volume, the WRS 8 checks if the rel- 
evant RFQ parameter 20 is set. If not, the WRS 8 sends 
a rejection message to the WTS 6 for the customer GUI 
2. If the relevant RFQ parameter 20 is set, the WRS 8 
sends an RFQ message to the WTS 6. At S5, the WTS 
6 receives the executable rate from the WRS 8 and 
checks if the deal amount exceeds the transaction limit. 
If not. the WTS 6 sends the executable rate to the cus- 
tomer GUI 2. If the deal amount exceeds the transaction 
limit, the WTS 6 checks if the relevant RFQ parameter 
18 is set If not. the WTS 6 sends a rejection message 
to the customer GUI 2. If the relevant RFQ parameter 1 8 
is set. the WTS determines that a request for quote is 
required. 

[0049] Fig. 7 is a flow chart which illustrates an 
example of the request for quote notification process for 
the request for quote aspect of an embodiment of the 
present invention. At S6, the WTS 6 receives a request 
for quote message from the WRS 8 or determines that 
a request for quote is required and sends a RFQ mes- 
sage to the customer GUI 2 and a RFQ notification to 
the MAI 6. At S7, the customer GUI 2 receives the RFQ 
message from the WTS 6, disables the "Buy" button 36, 
enables the "Re-request" button 40 and "Cancel" button 
38, and sets a RFQ timer. At S8. the MAI 10 receives 
the RFQ notification from the WTS 6 and sends the 
RFQ notification to the trader GUI 4. At S9, the trader 
GUI 4 displays a RFQ message on the request for quote 
message screen 44. At S10, the trader 14 enters a 
selection of the request for quote message from the 
message screen 44. At S11, the trader GUI 4 gets the 
transaction details from the WTS 6 and displays the 
details on the transaction details screen 46. 
[0050] Referring further to Fig. 7, at S12, the trader 
14 enters an acceptance by pressing the "Accept" but- 
ton 48 or a rejection by pressing the "Reject" button 50 
on the transaction details screen 46. At S13. the trader 
GUI 4 sends the trader's acceptance or rejection to the 
WTS 6. At S14. the WTS 6 sends the trader s accept- 
ance or rejection to the customer GUI 2. updates the 
request for quote status in the WTS transaction data- 
base, and broadcasts the updated status via the MA1 10 



to all on-line category traders. At S1 5, the customer GUI 
2 receives the trader's acceptance or rejection. If a 
rejection, the customer GUI 2 displays a refusal mes- 
sage for the customer 12. If an acceptance, the cus- 
5 tomer GUI 2 displays the trader's rate for the customer 
12. At S16, the customer 12 sees the display of the 
trader s rate and enters the customer's rejection by 
pressing the "Cancel" button 38 on the deal entry 
screen 30. Alternatively, if the customer 12 wants to 
10 accept the trader s rate and if the request for quote has 
not timed out, the customer 12 enters the customer's 
acceptance of the trader's rate by pressing the "Buy" 
button 36, and the transaction is executed. 
[0051] Another aspect for an embodiment of the 
is present invention is a sales trader feature, which pro- 
vides an automated system and method for warrant 
trading that allows a special type of trader, referred to as 
a sales trader, to deal on behalf of a selected customer 
within the CATS-OS system. Fig. 8 is a schematic dia- 
20 gram which illustrates an overview example of key com- 
ponents and the flow of information between the key 
components in the sales trader aspect for an embodi- 
ment of the present invention. The sales trader aspect 
for an embodiment of the present invention makes use, 
25 for example, of one or more sales trader GUIs 1 02. 1 04^ 
the warrants transaction server (WTS) 6, the warrants 
rate server (WRS) 8. as well as a credit server (CRS) 
1 06. a warrants hand-off server (WHO) 1 08 and a direct 
dealer interface (DDI) 110. In the sales wader aspect, 
so any number of sales traders 1 12, 1 14 perform this func- 
tion without necessarily knowing the price of particular 
warrants and without setting their own prices. Typically, 
but not necessarily, one or more of these traders 112, 
1 14 are located at terminals of the CATS-OS system, 
35 such as sales trader GUIs 102, 104, near the trading 
room itself. The sales traders 112, 114 receive calls 
from customers, such as customer 116, on the tele- 
phone 118 or other communication device in order to 
conduct trades for the customers. 
40 [0052] An advantage of the sales trader aspect for 
an embodiment of the present invention is that all the 
facilities of the CATS-OS system are available and fully 
met for the customers, including accurately set price, 
correctly collected information, and other requirements 
45 for deals to proceed, such as credit Ones in place. In 
addition the sales trader aspect provides the advantage 
of reduced error rates achieved by the CATS-OS sys- 
tem without the disadvantage of having to install all the 
CATS-OS system requirements for customers who do 
so not wish installation but who wish to continue to deal 
over the telephone 118. The sales trader aspect thus 
provides full warrant trading capabilities without the 
expense of highly paid professional traders or inter- 
bank traders. The sales trader aspect also includes spe- 
55 dalized features relating to trading by phone 118 and 
customer account access. In the sales trader aspect, 
the sales traders 112, 114 have privileged access to 
user accounts. In this embodiment, the sales traders 
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112, 1 14 do not have access to all capabilities that nor- 
mal users of the CATS-OS system have, but the system 
does provide the sales traders 1 12, 1 14 with the capa- 
bility to select the customers, such as customer 1 1 6, on 
whose behalf they are acting and to perform certain 5 
necessary functions to complete warrant trading. 
[0053] In the sales trader aspect of an embodiment 
of the present invention, when the sales traders 112, 
114 log in, input of name and password information 
allows the sales traders 1 1 2, 1 1 4 to deal on behalf of a 10 
number of users in a secure manner. The sales trader 
aspect permits a user to trade in the CATS-OS system 
on behalf of its customers and makes use, for example, 
of the GUI and the servers in the existing CATS-OS sys- 
tem to increase the number of warrants transactions 15 
done through the CATS-OS system. The sales trader 
aspect enables this by including warrants transactions 
done with customers, such as customer 116, over the 
telephone 118. This new type of user is able to enter 
transactions in the CATS-OS system on behalf of cus- 20 
tomers. 

[0054] As the existing CATS-OS system provides 
an automatic deal hand-off to the DD1 1 10, a benefit of 
the sales trader aspect for an embodiment of the 
present invention includes, for example, a significant 25 
reduction in the wrong rates being quoted or entered 
accidentally into the system by traders. Currently, many 
telephone trades are mismatched and have to be 
adjusted by a middle office. Another benefit of the sales 
trader aspect for an embodiment of the present inven- 30 
tion is to avoid manual work and hand-written tickets, 
thus saving time for the trader. An additional benefit of 
the sales trader aspect is that the CATS-OS system GUI 
software application need not be installed at the cus- 
tomer's site, because the sales traders, such as sales 35 
traders 112, 114, are able to enter and view transac- 
tions on behalf of customers. 

[0055] Fig. 9 is a schematic diagram which illus- 
trates an example overview of databases for the sales 
trader aspect of an embodiment of the present inven- 40 
tion. The sales trader aspect includes, for example, an 
"Institution" table 118, a "Branch" table 120. a "User- 
table 122. and a "Customer" table 124. In the sales 
trader aspect, the non- CATS-OS system bank counter- 
party details are manually entered into the "Branch" 45 
table 120 of the CATS-OS system. In addition, the trad- 
ing relationships and credit limits are manually main- 
tained from relationship and credit limit maintenance 
screens. The existing customers* GUI trading mecha- 
nism is not changed. The DDI 110 stores additional so 
fields, such as customer identification and retail cus- 
tomer's settlements instructions, in a DDI interface table 
and Exchange Feed table of the existing CATS-OS sys- 
tem. A customer list is uploaded from a text file into the 
CATS-OS system database. Thereafter, the "Customer" ss 
table 124 of the CATS-OS system is manually main- 
tained by a system administrator. The sales traders, 
such as sales traders 1 12, 114, do not have the privi- 



lege to negotiate prices or override maximum transac- 
tion amount being deleted. This privilege is available to 
traders who are able to respond to pending transactions 
that await request for quotes. 

[0056] The sales trader aspect for an embodiment 
of the present invention utilizes a number of servers. 
The WTS 6 coordinates the activities of the CATS-OS 
system. The WTS 6 contains a database which stores 
user profiles, transactions and relationships. The WRS 
8 receives input from price feeds, such as Reuters price 
feeds, and updates an in-memory table with the latest 
rates. The WRS 8 stores and updates volumes and war- 
rants instrument details. The CRS 106 maintains the 
credit for each branch. The credit is drawn down each 
time a transaction is executed. The WHO 108 receives 
the completed transactions and hands them off to the 
deal capture and position-keeping system or DDI 110. 
[0057] In the sales trader aspect for an embodiment 
of the present invention, the customer 1 1 6 is an individ- 
ual who has an account at a host retail bank branch, 
such as a global consumer bank. Alternatively, the cus- 
tomer 1 16 is a fund manager or broker of a corporate 
entity or bank that uses the CATS-OS system to execute 
warrants transactions against a branch of the host bank. 
The customer 1 16 is set up in the "User" table 122 with 
the user type "Customer" and a user ID as a unique 
identifier. The traders, such as trader 112. are the cor- 
porate warrants dealers at a branch of the host bank. A 
trader, such as trader 112, is responsible for making the 
prices, setting trading limits and covering positions 
resulting from transactions in local currency. The trader, 
such as trader 1 12, is set up in the "User" table 122 with 
user type Trader" with a unique identifier or user ID. A 
counterparty is the corporate entity, bank, or financial 
institution that uses the CATS-OS system to execute 
warrants transactions against a branch of the host bank. 
The counterparty is set up in the "Branch" table 1 20 with 
a unique identifier or branch ID. 
[0058] In the sales trader aspect for an embodiment 
of the present invention, a sales trader, such as trader 
1 12, is a new type of user of the CATS-OS system. For 
example, the sales trader 112 is either a host bank 
employee or a host bank broker who deals over the tel- 
ephone 1 18, tor example, with a host bank counterparty. 
The sales trader 1 12 is able to enter and view transac- 
tions on behalf of a customer 1 16 of the CATS-OS sys- 
tem. The customer 1 1 6 is also able to log into the CATS- 
OS system itself. The customer 116 can then be manu- 
ally added as a CATS-OS system user from a user pro- 
file maintain screen. An organization is classed as an 
"Institution" in the CATS-OS system. An institution is 
stored in the "Institution" table 118 with a unique identi- 
fier or institution ID. For example, a company called 
The Acme Company" is set up with an institution ID of 
"ACME INST." A branch is an instance of a bank branch 
or a corporate branch held in the "Branch" table 120 
with a branch ID. The Acme Company with branches in 
London, Frankfurt and Tokyo has branches, for exam- 



9 



aWSDCCID: rCD 1008 471 A3 I 



17 



EP 1 006 471 A2 



18 



pie. "LOIMACME", "FFTACME", and "TOKACME" set up 
in the CATS-OS system. 

[0059] In the sales trader aspect for an embodiment 
of the present invention, a relationship describes the 
trading relationship which the trading branch has with all s 
other host bank counterparties. As long as a trading 
relationship exists between the two relevant branches, a 
sales trader of the trading branch, such as sales trader 
112, can trade on behalf of any of the counterparties or 
the counterparty's retail customers, if any. Hence, a 10 
sales trader is not restricted to trade on behalf of a sub- 
set of counterparty customers. Fig. 10 is a schematic 
diagram which amplifies and provides further detail 
regarding the sample database overview shown in Fig. 
9 for the sales trader aspect of an embodiment of the 15 
present invention. In accordance with the existing 
CATS-OS system trading mechanism, all warrants 
transactions are done bank to bank. For example, a 
sales trader, such as sales trader 1 12, of the host bank 
in Japan trading on behalf of a retail customer or a glo- 20 
bal consumer bank, such as customer 116, results in 
the deal being done, for example, between "CITUPY" 
and "CITIGCB." 

[0060] In the sales trader aspect for an embodiment 
of the present invention, a sales trader transaction has 25 
its own time-out period for which the warrants price is 
valid. This time-out period is maintained in the "Branch" 
table 120 against the branch of the sales trader 112. 
The time-out period is longer, for example, than the nor- 
mal price time-out period. This is because there is some 30 
time delay between the buy/sell price being quoted to 
the customer 1 1 6 over the phone 1 1 8, and the customer 
1 1 6 stating the transaction volume and whether the cus- 
tomer 116 wishes to buy or sell. It is possible that the 
price of the warrant is updated in the meantime. The 35 
transaction is still executed with the buy/sell price 
quoted, as long as the sales trader time-out period does 
not expire. 

[0061] Figs. 11, 12. 13, 14. and 15 illustrate a sam- 
ple deal entry screen 1 30. a sample transaction screen 40 
132. branch maintenance screen 134, a sample cus- 
tomer maintenance screen 136, and a sample trade 
details screen 138, respectively, for the sales trader 
aspect of an embodiment of the present invention. The 
GUI 102 and the WTS 6 assure that the sales trader 45 
transaction is executed within the new time-out period. If 
not, the GU1 102 displays a time-out message and disa- 
bles the "Buy" button 1 40 and "Sell" button 1 42 from the 
deal entry screen 130. The sales trader 112 can then 
re-request a price quotation by pressing a the "Re- so 
request" button 144 or cancel the transaction by press- 
ing the "Cancel" button 146 on the deal entry screen 
130. When the sales trader 112 enters the warrants 
transaction in the CATS-OS system, the sales trader 
1 12 enters it as a broker of the trading branch. In other 55 
words, if the customer 1 16 says "I wish to buy X war- 
rants", the sales trader 1 12 enters "sell" by pressing the 
"Sell" button 142 on the deal entry screen 130 Similarly, 



if the customer 1 16 says "I wish to sell X warrants", the 
sales trader 1 1 2 enters "buy" by pressing the "Buy" but- 
ton 140 on the deal entry screen 130. 
[0062] In the sales trader aspect of an embodiment 
of the present invention, when the customer 116 tele- 
phones the sales trader 1 12 and requests to make war- 
rants transaction, the sales trader 112 at the sales 
trader GUI 102 logs into the CATS-OS system. The 
transaction screen 132 is displayed automatically to the 
user 1 12. The transaction screen 132 is more detailed 
than the one normally shown to the CATS-OS system 
customers. The sales trader 112 enters the warrants 
stock exchange number (SE No.) 148. The sales trader 
1 12 then enters a kV number 150 or depot number 152, 
if known. The kV number is given to banks or financial 
institutions that trade on the German stock exchange. 
Those with a kV number settle their account through the 
German clearing system. Those with a depot number 
are non-German banks or financial institutions that set- 
tle directly. The GU1 102 defaults to entry of kV number 
150. The kV number 150 or depot number 152 identifies 
domestic or non-domestic bank approved counterpar- 
ties. 

[0063] Alternatively, in the sales trader aspect for an 
embodiment of the present invention, the sales trader 
1 12 can enter the counterparty branch name 154. The 
sales trader 112 can request a list of branch names 
starting with x characters (maximum of eight charac- 
ters). If the sales trader 1 12 enters a search string and 
presses a "Find" button 156 on the branch maintenance 
screen 134, the GU1 102 ensures that some search cri- 
teria has been entered. The WTS 6 checks the "Branch" 
table 120 to see if the first few characters of the branch 
names match the search criteria. If matching branch 
names are found, the WTS 6 returns the total number of 
matching branch ID'S and names. If there are more than 
100 matching branch ID'S, the WTS 6 does not return 
any of the branch details and a message, such as "XXX 
matching branch names were found, please re-enter 
search criteria" is displayed. If none are found, a mes- 
sage is displayed, such as "None found; please re-enter 
search criteria." 

[0064] In the sales trader aspect for an embodiment 
of the present invention, for trading on behalf of retail 
bank customers, the sales trader 112 enters the cus- 
tomer ID 1 58, if known. Otherwise, the sales trader 1 12 
can request customer names starting with x characters 
(maximum of eight characters). If the sales trader 112 
enters a search string and presses the "Find" button 
160 on the customer maintenance screen 136. the GUI 
102 ensures that some search criteria has been 
entered. The WTS 6 checks the "Customer" table 124 to 
see if the first few characters of the customer names 
match the search criteria. If matching customer names 
are found, the WTS 6 returns the total number of match- 
ing customer ID's and names. If there are more than 
1 00 matching customer ID'S, the WTS 6 does not return 
any of the customer details and a message, such as 
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"XXX matching customer names were found, please re- 
enter search criteria" is displayed. If none are found, a 
message is displayed, such as "None found; please re- 
enter search criteria." 

[0065] In the sales trader aspect of an embodiment 
of the present invention, the sales trader 1 12 does not 
know the volume the customer 116 wishes to buy or 
sell. Once the CATS-OS system quotes a buy and sell 
price, the customer 116 decides the volume and 
whether to buy/sell. The sales trader 1 12 can request a 
price quotation by pressing a "Get Price" button 162 on 
the transaction screen 132. The QU1 102 ensures that a 
kV or a depot number has been entered. Otherwise, a 
message is displayed, such as "Please enter a kV/depot 
no or counterparty name," and the sales trader 112 is 
prompted for re-input. The WTS 6 then validates the kV 
or depot number entered. If the counterparty specified 
does not exist, then the system administrator must man- 
ually enter this branch, its trading relationship with a 
trading branch, and credit limits in the CATS-OS sys- 
tem, and a message will be displayed, such as "Invalid 
branch". If a customer ID is entered, the WTS 6 vali- 
dates that it exists in the "Customer" table 124. If not, a 
message will be displayed, such as "Invalid customer". 
The system administrator must manually enter the cus- 
tomer details in the customer maintenance screen 136. 
On successful validation, the WRS 8 generates a two- 
way price quote, which is both the buy and sell price for 
sales trader transactions. Before executing the transac- 
tion, the sales trader 1 12 must enter the volume. If not. 
the GU1 1 02 prompts the sales trader 1 1 2 for re-entry of 
the volume field. Once the customer 116 accepts the 
rate quoted within the new time-out period, the sales 
trader 112 executes the transaction by pressing either 
the "Buy" button 140 or the "Sell" button 1 42 on the deal 
entry screen 130. 

[0066] In the sales trader aspect for an embodiment 
of the present invention, if the CATS-OS system is una- 
ble to quote a price and the relevant request for quote 
(RFQ) parameters are switched on, the WTS 6 and/or 
the WRS 8 triggers a RFQ to the relevant category trad- 
ers that are logged in. The GUI displays a message indi- 
cating the reason for a RFQ. The sales trader 112 then 
waits for a trader to respond to the RFQ and quote a 
price. Otherwise, the sales trader 112 can re-request a 
price or cancel the transaction. The WTS 6 and the 
WRS 8 check to determine whether the deal amount 
exceeds the maximum transaction limit and whether the 
deal amount exceeds the available volume. If so, and 
the relevant RFQ parameters are switched on, a RFQ is 
triggered. The GUI displays a message indicating the 
reason for the RFQ. The sales trader 112 then waits for 
a trader to respond to the RFQ and quote a price. Oth- 
erwise, the sales trader 112 can re-request a price or 
cancel the transaction. When the sales trader 1 12 exe- 
cutes or cancels a transaction, the sales trader's branch 
credit limit is updated accordingly. 
[0067] In the sales trader aspect of an embodiment 



of the present invention, the sales trader 112 sees the 
customer maintenance screen 136. In a customer refer- 
ence field, the sales trader 112 enters the counter- 
party's employee name. The customer reference field 

5 can be used to view transactions and reports. On suc- 
cessful execution, the WTS 6 updates the volume on 
the transaction table. The transaction is then automati- 
cally handed to the DDI 110. For example, for every 
Japanese sales trader warrants transactions handed off 

to to the DD1 1 10, the WHO 108 sends additional fields to 
the DDI 1 10. These are the customer ID 164, such as 
the retail customer bank account number, and the retail 
customer name 166. The customer ID 164 and name 
1 66 fields are valid for transactions with retail bank cus- 

75 tomers; otherwise, it is blank. The retail customer's set- 
tlements instructions, i.e.. customer ID 164 and name 
166, are deemed a mandatory field, for example, for 
Japanese back office settlements operations. The WTS 
6 hands off the customer ID and name for every trans- 

20 action to the WHO 108. The WHO 108 only hands off, 
for example, the additional two fields for Japanese 
transactions. 

[0068] In the sales trader aspect of an embodiment 
of the present invention, for those banks or financial 

25 institutions that do not settle, for example, through a 
German clearing house, the warrants transaction 
amounts are settled directly between the trading bank 
or financial institution and the counterparty bank or 
financial institution. This is done using a depot number, 

30 such as the branch plus a base plus an account 
number. German banks or financial institutions that go 
through the clearing house settle, for example, by using 
the German stock exchange number or kV number in 
the DDI 110. For warrants transactions with retail bank 

35 customers, their accounts are settled, for example, by a 
back office settlements system. 
[0069] In an embodiment of the present invention, 
for sates trader transactions, deal tickets show a sales 
trader user ID and counterparty customer ID. An 

40 "Entered by" field in the deal ticket is the sales trader's 
user ID. The WTS 6 generates deal tickets with addi- 
tional fields, such as the customer's ID and customer's 
name. These are only valid for sales trader transactions 
executed on behalf of retail bank customers. Otherwise 

45 they are blank. For sales trader transactions, transac- 
tion reports show the sales trader's user ID and counter- 
party's customer ID. The "Entered by" field 168 in the 
transaction report is the sales trader's user ID. The WTS 
6 generates transaction reports with additional fields, 

so such as the customer's Id and retail customer's settle- 
ments instructions. These are only valid for sales trader 
transactions executed on behalf of retail bank custom- 
ers. Otherwise they are blank. 

[0070] In the sales trader aspect of an embodiment 
55 of the present invention, for sales trader transactions, 
two way price quotation is necessary. When the sales 
trader 112 enters a transaction and the CATS-OS sys- 
tem is unable to quote prices, an RFQ is triggered if the 
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RFQ parameters are switched on. In other words, cate- 
gory traders are expected to respond to an RFQ and 
quote a two way price. An RFQ may be triggered if the 
rate, instrument, counterparty, or system is suspended, 
or if the deal amount is greater than the maximum trans- 
action limit or the deal amount is greater than available 
volume. The volume and buy/sell field may be blank for 
sales trader transactions. The QUI and the WTS 6 
ensure that the trader responds within the new time-out 
period for sales trader transactions. 
[0071] Fig. 16 is a flow chart which illustrates a 
sample sales trader transaction for the sales trader 
aspect of an embodiment of the present invention. At 

5 10 1 , the customer 1 1 6 at a telephone 1 1 8 contacts the 
sales trader 112 and requests a warrants transaction. At 

5102, the sales trader 112 at the sales trader QUI 102 
logs in and inputs the sales trader's name and password 
information, enters the customer's warrants transaction 
information, and presses the "Get Price" button 162 for 
a price quote request. At S103, the sales trader GU1 104 
sends the price quote request to the WTS 6. At S104, 
the WTS 6 validates the entered information, checks 
RFQ parameters, and if applicable, triggers the RFQ 
process; or if not applicable, sends the price quote 
request to the WRS 8. 

[0072] Referring further to Fig. 16. at S105, the 
WRS 8 checks RFQ parameters, and if applicable, trig- 
gers the RFQ process; or if not. generates a two-way 
buy-sell price quote and sends it to the WTS 6. At S1 06, 
the WTS 6 sends the price quote to the sales trader GUI 
112. At S112, the sales trader GUI 102 displays the 
price quote for the sales trader. At S114, the sales 
trader 112 communicates the price quote to the cus- 
tomer 1 16. At S107. the customer 116 responds to the 
sales trader 112 with the customer's decision to reject 
or accept the price quote, and if accepted by the cus- 
tomer 1 16, the customer's desired volume. At S108, the 
sales trader 112 enters the customer's rejection by 
pressing the "Cancer button 146, or if accepted by the 
customer 116, enters the customer's desired volume 
and executes the transaction by pressing the "Buy" but- 
ton 1 40 or "Seir button 1 42. 

[0073] An additional aspect for an embodiment of 
the present invention is a multi-bank feature, which pro- 
vides a system and method for automated warrant trad- 
ing that allows a plurality of banks to deliver their prices 
using the CATS-OS system. The multi-bank aspect ena- 
bles the single bank CATSOS system to perform in a 
multi-bank mode by establishing links to one or more 
additional banks. Trading data is collected from the 
other banks, and once a deal is done, the deal is 
returned to a particular bank so that it can then manage 
the position which it has and perform its own assess- 
ment and the like. The multi-bank aspect for an embod- 
iment of the present invention converts the single bank t 
automated warrant trading CATS-OS system to a multi- 
bank automated warrant trading system and method. 
[0074] Fig. 17 is a schematic diagram which illus- 



trates an example overview example of key components 
and the flow of information between the key compo- 
nents for the multi-bank aspect of an embodiment of the 
present invention. The multi-bank aspect avoids the 
5 potential problem of being overly embedded. For exam- 
ple, if a bank offers competing prices, there are potential 
regulatory problems, such as a claim that the bank is 
conducting a stock exchange. In other words, when a 
bank allows many different competing prices on one 
10 system, the system may be claimed to be in effect a 
stock exchange. The multi-bank aspect for an embodi- 
ment of the present invention avoids the claim that it is a 
stock exchange, because the system does not have 
direct price competition between different banks using 
is the multi-bank aspect of the system. 

[0075] The single bank CATS-OS system is an end 
tier client-server system, an advantage of which is that 
the different functions are very well partitioned. The 
functions of the single bank system include the rate 
20 server or WRS, which receives and fulfills rate requests 
from the transaction server or WTS, and a hand-off 
server or WHO, which hands off complete transactions 
to a direct dealer interface or DDI. The WRS receives 
rights from the bank and manages and presents them to 
25 the rest of the system as required, and the WHO 
receives bills from the system and hands them off to the 
bank and provides a reconciliation process. The single 
bank CATS-OS system also includes the WTS and lay- 
ers of security and messaging which tie the whole sys- 
30 tern together. 

[0076] In the multi-bank aspect of an embodiment 
of the present invention, in addition to a first bank's WTS 
6, for example, one or more additional transaction serv- 
ers, such as a second bank's WTS 202, are errployed. 
35 which are completely independent from the first bank's 
WTS 6 and completely independent from one another. 
Each additional transaction server, such as the second 
banks WTS 202, deals exclusively with an additional 
bank, such as the second bank, in the multi-bank aspect 
40 for an embodiment of the present invention. Likewise, 
one or more additional rate servers, such as the second 
banks WRS 204, and one or more additional hand-off 
servers, such as the second bank's WHO 206, are pro- 
vided, which enables segregation between the multiple 
45 banks. A customer 208 uses a graphical user interface 
(GUI) 210 coipled via a network 21 2 to shared commu- 
nications and messaging layers 214 to the separate 
automated warrant trading systems of a plurality of 
banks, such as trading systems 2 1 6 and 218. 
30 [0077] In the multi-bank aspect for an embodiment 
of the present invention, the separate automated war- 
rant trading systems 216 and 218 of each bank 
includes, for example, the separate transaction servers 
WTS 6 and WTS 212 coupled to the shared communi- 
!5 cations and messaging layers 214, and the separate 
rate servers WRS 8 and WRS 204 and hand-off servers 
WHO 7 and WHO 216 coupled to the respective trans- 
action servers WTS 6 and WTS 202. Further, each 
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bank's separate trading system 21 6, 21 8 includes a fire- 
wall 220, 222, established between the respective 
banks' rate servers WRS 8 and WRS 204 and hand-off 
servers WHO 7 and WHO 216, and the respective 
banks' data centers 224, 226. Thus, one bank on the 5 
multi-bank system is not allowed to see how another 
bank on the system deals with the particular customer 
208. While the multi-bank aspect utilizes shared com- 
munications and messaging layers 214, it runs inde- 
pendently on each end user's system. The multi-bank to 
aspect is transparent to each of the banks using the 
system. As far as a particular bank using the multi-bank 
system is concerned, it is the only bank on the system. 
[0078] Currently, the CATS-OS system runs very 
successfully as an automated electronic trading tool for 15 
a bank's customers, for example, in Germany. These 
customers are primarily brokers, so the bank is often not 
aware of the identity of the end customer. The multi- 
bank aspect for an embodiment of the present invention 
allows other banks to add their prices to the CATS-OS 20 
system, so these brokers can buy and sell their warrants 
as well. This has an advantage for the brokers in that 
they only have to deal with one system to in order to 
meet their customers' needs. The multi-bank aspect for 
an embodiment of the present invention enables an 25 
entity, such as a wholly owned subsidiary of a bank, to 
provide a system which dears with hundreds of other 
banks, corporations and/or fund managers by demon- 
strating the ability of the subsidiary to maintain a sepa- 
ration between the bank and itself, as well as all other 30 
parties. Such an entity can be responsible for both the 
software and hardware for the CATS-OS system and 
can run the system in its own data center 228 and pro- 
vide a clearly defined hand-off between its parent bank 
and itself. 35 
[0079] The multi-bank aspect of an embodiment of 
the present invention enables the CATS-OS system 
user 208 to easily buy and sell warrants from a number 
of banks and market makers. If the user 208 accesses 
the system through dial-up, the user 208 does not to 40 
have to disconnect and re-dial to deal with another 
bank. The user 208 does not to have to log in sepa- 
rately, for example, to each of the systems 216, 218. 
Further, the systems 216, 218 are not so integrated as 
to raise fears that a stock exchange is created. Addition- 45 
ally, segregation between price makers is maintained. 
The multi-bank aspect for an embodiment of the present 
invention provides a fast, secure and reliable method of 
extracting rates from the price maker and returning to 
the bank any resultant deals in a timely and reliable so 
fashion. 

[0080] In the multi-bank aspect for an embodiment 
of the present invention, an extra level of functionality 
can be added to the current user front-end GUI to allow 
the extra banks to be vistole. Alternatively, for a rela- 55 
tively small number of banks, the GUI can be run a 
number of times, once for each available bank. In the 
alternative approach, the user 208 simply clicks from 



one system to the other as needed. A mechanism is 
also provide to enable this with the keyboard only. This 
can be accomplished, for example, with changes to the 
GUI and a higher specification machine to run more 
than one program at once. In the multi-bank aspect for 
an embodiment of the present invention, users of both 
the first bank's system 216 and the second bank's sys- 
tem 218 only have access to the systems via their GUIs, 
and segregation of ail functions are maintained. An 
entity such as a subsidiary of the first bank can act in 
the mode of system administrator. A decision can be 
made as to which customers are enabled for which 
banks. The system can still be used as a single bank 
system as needed. Predetermined business arrange- 
ments are entered, for example, between the first bank, 
its subsidiary and the other banks, such as the second 
bank. 

[0081] Fig. 18 is a flow chart which illustrates an 
example of the process of a customer transaction in the 
multi-bank aspect for an embodiment of the present 
invention. At S201, the customer 208 at the customer 
GUI 210 logs on and enters the customer's price quote 
request. At S202, the customer GUI 210 sends the price 
quote request via shared communication and messag- 
ing layers 214 simultaneously to the WTS 6 and the 
WTS 202 of the separately maintained and segregated 
trading systems 216 and 218. At S203. the WTS 6 and 
the WTS 202 each sends the price quote request to the 
corresponding WRS 8 and WRS 204 of its own trading 
system 216 or 218. At S204, each of the WRS 8 and 
WRS 204 independently generates an executable rate 
and sends the rate to the corresponding WTS 6 and 
WTS 202 of its own trading system 218 or 218. At S205, 
each of the WTS 6 and the WTS 202 sends its own trad- 
ing system's rate quote via the shared communication 
and messaging layers 214 to the customer GUI 210. 
[0082] Referring further to Fig. 18, at S206, the cus- 
tomer GUI 210 receives and displays each of the rate 
quotes, such that the rate quote and the identity of the 
financial institution's trading system 216 or 218 which 
furnished the rate quote are known only to the customer 
208 and the financial institution which furnished the rate 
quote. At S207. the customer 208 at the customer GUI 
210 enters the customer's selection of one of the rate 
quote furnished by one of the trading systems 216 or 
218. At S208, the customer GUI 210 sends the cus- 
tomer's acceptance via the shred communication and 
messaging layers 214 to the WTS 6 or the WTS 202 of 
the trading system 216 or 218 which furnished the 
selected rate quote, such that the selection is known 
only to the customer 208 and the financial institution 
whose trading system 21 6 or 21 8 furnished the selected 
rate quote. At S209, the WTS 6 or the WTS 202 of the 
trading system 216 or 218 which furnished the selected 
rate quote receives the customer's acceptance and 
sends the acceptance to corresponding WHO 7 or 206 
of the trading system 216 or 218 which furnished the 
selected rate quote for processing. 
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[0083] Although the invention has been described 
with reference to these preferred embodiments, other 
embodiments can achieve the same results. Variations 
and modifications of the present invention will be appar- 
ent to one skilled in the art, and the above disclosure is 
intended to cover all such modifications and equiva- 
lents. Accordingly, the invention is only limited by the fol- 
lowing claims. 

Claims 

1 - A method for data management of a financial trans- 
action, comprising: 



2. The method of claim 1. wherein receiving the 
request for the proposed financial transaction fur- 
ther comprises receiving the request at a terminal 
(2, 210; 4, 102, 104). 

3. The method of claim 2, wherein receiving the 
request at the terminal (2, 210) further comprises 
entering the request at the terminal (2, 210) by the 
user (12, 116, 208). 

4. The method of claim 2, wherein receiving the 
request at the terminal (4, 102, 104) further com- 
prises entering the request at the terminal (4. 102, 
104) for the user (12, 116, 208) by a sales trader 
(112,114). 

5. The method of claim 4, wherein entering the 
request at the terminal (4, 102, 104) by the sales 



trader (112, 114) further comprises receiving the 
request by the sales trader (1 12, 1 14) from the user 
(116,208). 

s 6. The method of claim 2, wherein receiving the 
request at the terminal (2, 210; 4, 102, 104) further 
comprises receiving the request by a transaction 
server (6, 202) coupled to the terminal (2, 210; 4, 
102, 104). 

7. The method of claim 6, wherein receiving the 
request at the terminal (2, 210; 4, 102, 104) further 
comprises receiving the request by a rate server (8, 
204) coupled to the transaction server (6, 202). 

8. The method of claim 2, wherein receiving the 
request at the terminal (2, 210; 4, 102, 104) further 
comprises receiving the request by a plurality of 
transaction servers (6, 202) coupled to the terminal 
(2,210; 4, 102, 104). 

9. The method of claim 8, wherein receiving the 
request at the terminal (2, 210; 4, 102, 104) further 
comprises receiving the request by the transaction 
servers (6, 202) of each of a plurality of independ- 
ently maintained and segregated trading systems 
(216, 218) coupled to the terminal (2. 210; 4. 102, 
104). 

10. The method of claim 9, wherein receiving the 
request at the terminal (2, 210; 4, 102, 104) further 
comprises receiving the request by a correspond- 
ing rate server (8, 204) coupled to the transaction 
server (6, 202) of each of the trading systems (216, 
218). 

11- The method of claim 1, wherein generating the rate 
quote further comprises automatically identifying 
the first predefined condition for generating the exe- 
cutable rate quote for the proposed transaction by 
at least one of a transaction server (6, 202) and a 
rate server (8, 204). 

12. The method of claim 11, wherein automatically 
identifying the first predefined condition for generat- 
ing the executable rate quote further comprises 
automatically generating the executable rate quote 
by the rate server (8. 204). 

so 1 3. The method of claim 12, wherein automatically gen- 
erating the executable rate quote by the rate server 
(8, 204) further comprises automatically generating 
the executable rate quote by the rate server (8, 204) 
coupled to the transaction server (6. 202). 

55 

14. The method of claim 12, wherein automatically gen- 
erating the executable rate quote by the rate server 
(8, 204) further comprises automatically generating 



receiving a request for a user (1 2, 1 1 6, 208) for is 
a proposed financial transaction; 
generating a rate quote consisting of one of an 
executable rate quote and a category trader's 
rate quote for the proposed financial transac- 
tion, wherein the executable rate quote is gen- 20 
erated if a first predefined condition is 
identified, and the category trader's rate quote 
is generated rf a second predefined condition is 
identified; 

automatically prompting the user (12,116, 208) 2s 
for a selection of the generated rate quote for 
the proposed financial transaction; 
automatically holding the generated rate quote 
for a predetermined period of time for the user 
(12, 116,208); 30 
receiving a request for execution of the pro- 
posed transaction for the user (1 2, 1 16, 208) in 
accordance with the selection by the user (12, 
1 1 6, 208) of the generated rate quote; and 
automatically executing the proposed transac- 35 
tion for the user (12, 116, 208) in accordance 
with the generated rate quote upon receipt of 
the request for execution within the predeter- 
mined period of time. 
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the executable rate quote by the rate server (8, 204) 
of at least one of a plurality of independently main- 
tained and segregated trading systems (216, 218). 

1 5. The method of claim 1 4 , wherein automatically gen- s 
erating the executable rate quote by the rate server 

(8, 204) of at least one of the plurality of trading sys- 
tems (216, 218) further comprises automatically 
generating the executable rate quote by the rate 
server (8, 204) coupled to a corresponding transac- io 
tion server (6. 202) of the at least one independ- 
ently maintained and segregated trading system 
(216, 218). 

1 6. The method of claim 1 , wherein generating the rate is 
quote further comprises automatically identifying 

the second predefined condition for generating the 
category trader's rate quote. 

17. The method of claim 16, wherein automatically 20 
identifying the second predefined condition for gen- 
erating the category trader's rate quote further com- 
prises automatically identifying a predefined cause 

for rejecting the request for the proposed financial 
transaction. 25 

18. The method of claim 17, wherein automatically 
identifying the predefined cause for rejecting the 
request for the proposed financial transaction fur- 
ther comprises automatically identifying the prede- 30 
fined cause for rejecting the proposed financial 
transaction by at least one of a transaction server 

(6, 202) and a rate server (8, 204). 

19. The method of claim 18, wherein automatically 35 
identifying the predefined cause for rejecting the 
proposed financial transaction further comprises 
automatically identifying at least one cause for 
rejecting the proposed financial transaction 
selected from a group of causes for rejecting the 40 
proposed financial transaction consisting of a pro- 
posed transaction counterparty suspension, a pro- 
posed transaction system suspension, a proposed 
transaction instrument suspension, a proposed 
transaction rate suspension, a proposed transac- 45 
tion volume exceeding an available volume, and a 
proposed transaction amount exceeding a prede- 
fined limit. 

20. The method of claim 1 7, wherein automatically gen- so 
erating the request for the category trader's rate 
quote further comprises automatically confirming a 
predetermined setting of a request for quote param- 
eter corresponding to the at least one identified pre- 
defined cause for rejection of the proposed financial ss 
transaction. 

21 . The method of claim 20, wherein automatically con- 



firming the request for quote parameter setting fur- 
ther comprises automatically confirming the 
request for quote parameter setting by at least one 
of the transaction server (6. 202) and the rate 
server (8, 204). 

22. The method of claim 16, wherein automatically 
identifying the second predefined condition for gen- 
erating the category trader's rate quote further com- 
prises automatically prompting entry of the 
category trader s rate quote by at least one of a plu- 
rality of category traders. 

23. The method of claim 22, wherein automatically 
prompting the entry of the category trader's rate 
quote further comprises receiving an input of the 
category trader's rate quote by at least one of the 
plurality of category traders. 

24. The method of claim 1, wherein automatically 
prompting the user (12, 116, 208) for selection of 
the generated rate quote further comprises auto- 
matically displaying the generated rate quote for the 
user (12, 116, 208). 

25. The method of claim 24, wherein automatically dis- 
playing the generated rate quote further comprises 
automatically displaying the generated rate quote 
for the user (12, 116, 208) at a terminal (2, 210; 4, 
102. 104). 

26. The method of claim 25, wherein automatically dis- 
playing the generated rate quote further comprises 
automatically displaying the generated rate quote at 
a user terminal (2, 210) for the user (12, 116, 208). 

27. The method of claim 25, wherein automatically dis- 
playing the generated rate quote automatically dis- 
playing the generated rate quote at a sales trader 
terminal (4, 102. 104) for the user (12, 116, 208). 

28. The method of claim 1 , wherein automatically hold- 
ing the generated rate quote for the predetermined 
period of time for the user (12, 116, 208) further 
comprises automatically setting a counter for the 
predetermined period of time. 

29. The method of claim 1, wherein receiving the 
request for execution of the proposed transaction 
further comprises receiving the request for execu- 
tion at a terminal (2. 210; 4, 102. 104). 

30. The method of claim 29, wherein receiving the 
request for execution at the terminal <2, 210; 4, 102. 
104) further comprises entering the request at a 
user terminal (2, 210) by the user (12, 116, 208). 

31. The method of claim 30. wherein receiving the 
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request for execution at the terminal (2, 210; 4, 102, 
104) further comprises entering the request at a 
sales trader terminal (4, 102, 104) by a sales trader 
(14,112, 114) for the user (12, 116,208). 

5 

32. The method of claim 31, wherein entering the 
request for execution at the sales trader terminal (4, 
102, 104) by the sales trader (14, 112, 1 14) further 
comprises receiving the request by the sales trader 
(14, 112, 114) from the user (12, 116,208). 10 

33. The method of claim 29, wherein receiving the 
request for execution at the terminal (2, 210; 4, 102, 
104) further comprises receiving the request for 
execution by a transaction server (6, 202) coupled is 
to the terminal (2; 210; 4, 102, 104). 

34. The method of claim 33, wherein receiving the 
request for execution at the terminal (2, 210; 4, 102, 
104) further comprises receiving the request for 20 
execution by the transaction server (6, 202) of one 

of a plurality of independently maintained and seg- 
regated trading systems (216, 218) coupled to the 
terminal (2, 210; 4, 102, 104). 

25 

35. The method of claim 1, wherein automatically exe- 
cuting the proposed transaction for the user (12. 
116. 208) further comprises automatically handing 
off the request for execution to a hand-off server (7, 
108,206). 30 

36. The method of claim 35, wherein automatically 
handing off the request for execution further com- 
prises automatically handing off the request for exe- 
cution by a transaction server (6, 202). 35 

37. The method of claim 35, wherein automatically 
handing off the request for execution further com- 
prises automatically handing off the request for exe- 
cution by a transaction server (6. 202) of one of a 40 
plurality of independently maintained and segre- 
gated trading systems (216, 218). 

38. A system for data management of a financial trans- 
action, comprising: 45 

means for receiving a request for a user (12, 
116, 208) for a proposed financial transaction; 
means coupled to the transaction request 
receiving means for generating a rate quote so 
consisting of one of an executable rate quote 
and a category trader's rate quote for the pro- 
posed financial transaction, wherein the exe- 
cutable rate quote is generated if a first 
predefined condition is identified, and the cate- 55 
gory trader's rate quote is generated if a sec- 
ond predefined condition is identified; 
means coupled to the rate generating means 



for automatically prompting the user (12, 116. 
208) for a selection of the generated rate quote 
for the proposed financial transaction; 
means associated with the prompting means 
for automatically holding the generated rate 
quote for a predetermined period of time for the 
user (12, 116, 208); 

means associated with the prompting means 
for receiving a request for execution of the pro- 
posed transaction for the user (12, 116, 208) in 
accordance with the selection by the user (12, 
1 16, 208) of the generated rate quote; and 
means coupled to the execution request receiv- 
ing means for automatically executing the pro- 
posed transaction for the user (12, 116. 208) in 
accordance with the generated rate quote upon 
receipt of the request for execution within the 
predefined period of time. 

39. The system of claim 38, wherein the means for 
receiving the request for the proposed financial 
transaction further comprises a terminal (2, 210; 4, 
102, 104) consisting of one of a user's terminal (2, 
210) and a sales trader's terminal (4, 102, 104). 

40. The system of claim 39. wherein the means for 
receiving the request for the proposed financial 
transaction further comprises at least one transac- 
tion server (6, 202) coupled to the terminal (2, 210; 
4, 102, 104). 

41. The system of claim 40, wherein the means for 
receiving the request for the proposed financial 
transaction further comprises a rate server (8, 204) 
coupled to the transaction server (6, 202). 

42. The system of claim 39, wherein the means for 
receiving the request for the proposed financial 
transaction further comprises a plurality of transac- 
tion servers (6, 202) coupled to the terminal (2, 210; 
4, 102, 104). 

43. The system of claim 42, wherein the means for 
receiving the request for the proposed financial 
transaction further comprises the transaction serv- 
ers (6, 202) of each of a plurality of independently 
maintained and segregated trading systems (216, 
218) coupled to the terminal (2, 210; 4, 102, 104). 

44. The system of claim 43, wherein the means for 
receiving the request for the proposed financial 
transaction further comprises a corresponding rate 
server (8, 204) coupled to the transaction server (6, 
202) of each of the trading systems (216, 218). 

45. The system of claim 38, wherein the means for gen- 
erating the rate quote for the proposed financial 
transaction further comprises means for identifying 
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the first predefined condition for generating the exe- 
cutable rate quote. 

46. The system of claim 45, wherein the means for 
identifying the first predefined condition for generat- 5 
ing the executable rate quote further comprises at 
least one of a transaction server (6, 202) and a rate 
server (8, 204). 

47. The system of claim 46, wherein the means for gen- 10 
erating the rate quote for the proposed financial 
transaction further comprises the rate server (8, 
204) for generating the executable rate quote cou- 
pled to the transaction server (6, 202). 

75 

48. The system of claim 47, wherein the means for gen- 
erating the rate quote for the proposed financial 
transaction further comprises the rate server (8, 
204) of at least one of a plurality of independently 
maintained and segregated trading systems (216, 20 
218). 

49. The system of claim 48, wherein the means gener- 
ating the rate quote further comprises the rate 
server (8, 204) coupled to a corresponding transac- 25 
tion server (6, 202) of the at is least one independ- 
ently maintained and segregated trading system 
(216. 218). 

50. The system of claim 38, wherein the means for gen- 30 
erating the rate quote for the proposed financial 
transaction further comprises means for automati- 
cally identifying the second predefined condition for 
generating the category trader's rate quote. 

35 

51. The system of claim 50, wherein the means for 
automatically identifying the second predefined 
condition for generating the category trader's rate 
quote further comprises at least one of a transac- 
tion server (6, 202) and a rate server (8. 204). 40 

52. The system of claim 38. wherein the means for gen- 
erating the rate quote for the proposed financial 
transaction further comprises means for automati- 
cally prompting entry of the category trader's rate 45 
quote by at least one of a plurality of category trad- 
ers. 

53. The system of claim 52, wherein the means for 
automatically prompting entry of the category so 
trader's rate quote further comprises at least one 
category trader's terminal coupled to a transaction 
server (6, 202). 

54. The system of claim 38, wherein the means for ss 
automatically prompting the user (12, 116, 208) for 
selection of the generated rate quote further com- 
prises a terminal (2, 210; 4, 102, 104) consisting of 



one of a user's terminal (2, 21 0) and a sales trader's 
terminal (4, 102, 104). 

55. The system of claim 54, wherein the means for 
automatically prompting the user (12, 1 16, 208) for 
the selection of the generated rate quote further 
comprises at least one transaction server <6, 202) 
coupled to the terminal (2, 210; 4, 102. 104). 

56. The system of claim 55, wherein the means for 
automatically prompting the user (12, 1 16, 208) for 
the selection of the generated rate quote further 
comprises a rate server (8, 204) coupled to the 
transaction server (6, 202). 

57. The system of claim 54, wherein the means for 
automatically prompting the user (12, 116, 208) for 
the selection of the generated rate quote further 
comprises a plurality of transaction servers (6, 202) 
coupled to the terminal (2, 210; 4, 102, 104). 

58. The system of claim 57, wherein the means for 
automatically prompting the user (12, 116, 208) for 
the selection of the generated rate quote further 
comprises the transaction servers (6, 202) of each 
of a plurality of independently maintained and seg- 
regated trading systems (216, 218) coupled to the 
terminal (2. 210; 4. 102. 104). 

59. The system of claim 58, wherein the means for 
automatically prompting the user (12, 1 16, 208) for 
the selection of the generated rate quote further 
comprises a corresponding rate server (8, 204) 
coupled to the transaction server (6, 202) of each of 
the trading systems (216, 218). 

60. The system of claim 38. wherein the means for 
automatically holding the generated rate quote for a 
predefined period of time further comprises a coun- 
ter. 

61. The system of claim 38, wherein the means for 
receiving the request for execution of the proposed 
transaction for the user (12, 1 16, 208) further com- 
prises a terminal (2, 210; 4, 102, 104) consisting of 
one of a user's terminal (2, 21 0) and a sales trader's 
terminal (4. 102. 104). 

62. The system of claim 61, wherein the means for 
receiving the request for execution of the proposed 
transaction forte user (12, 116. 208) further com- 
prises a transaction server (6, 202) coupled to the 
terminal (2. 210; 4, 102, 104). 

63. The system of claim 62. wherein the means for 
receiving the request for execution of the proposed 
transaction for the user (12, 1 16, 208) further com- 
prises the transaction server (6, 202) of one of a 
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plurality of independently maintained and segre- 
gated trading systems (21 6, 21 8) coupled to the ter- 
minal (2. 210; 4, 102, 104). 

64. The system of claim 38. wherein the means for 5 
automatically executing the proposed financial 
transaction further comprises a transaction server 

(6. 202) coupled to a hand-off server (7, 108, 206). 

65. The system of claim 64, wherein the means for w 
automatically executing the proposed financial 
transaction further comprises the transaction 
server (6, 202) and the hand-off server (7, 108, 
206) of one of a plurality of independently main- 
tained and segregated trading systems (216, 218). 15 



18 



EP 1 006 471 A2 




19 



EP 1 006 471 A2 



□ 



□ 



O 



a 



-a 

CO 

CO 



at 

I ff s 

» 2 § s 
t3 <| o £. 
£ U w 



t= S % 

3 w 

cd <l> <D 



Q 
L 



<k| rr so oo 
(N fM (N (S 



oo O 




o 
Ul 



Dl 



•4— » 

-o 
a 



0> 

> 

O 

B 



•o 

<l 



c 

5j 



d 

to 



VO 



JJUU1D I iin jdd ilium inu I I. 



20 



EP 1 006 471 A2 



■n 
□ 



D 



o 
o 



oo 



O 

c 



I— I 

< 



o 
> 

> 



12 



t 

to 

Q 

O 
H 



o 
oo 



a 

















ON 










ON 














ro 










r- 






o 




NO 






NO 

















CO 

oil 



E 



O 
CO 



£ 

3 

? 



<1> 
O 

I 



■*— ♦ 
03 

Q 



o 

CO 



—r 



iwanrrnrv rFP mnfU7iA'j i * 



21 



EP 1 006 471 A2 




22 



EP 1 006 471 A2 



□ 



o 

"4— » 

o 

u 
O 

CO 

cr 



"2 « 

CO 



c « 
S « 

1 § 



<L> 

tn 



g o >, 
J5 O &o 



C 
Z3 

o 



X 



CO 

u 



03 

CO 

o 

o 
X 



o 

Oh 
> 



03 

<>••§ 
SI 



0> 

o 
D 




CO 

*c3 

4— » 

CD 

Q 



o >^ 

etf 3 

5 



£ «J "3 OQ 

3 £5 Q -o 
> ffl - £ 



Q 

c 

E 



CO 



E 
5 

CO 
C 



§0 
o w 



a 



2 
< 



H 3 2 « 8 

II SSi 

o O c3 





VO 



23 



EP 1 006 471 A2 



Customer Logs on Customer GUI and Enters Instrument ID, 
Volume, and Indicates Buy or Sell Warrant 

t — 

Customer GUI Validates Details and Sends Rate Quote 
Request to WTS 

i 

WTS Receives Rate Request, Checks if 
Counterparty/system Suspended; if No, Sends Rate Request 
to WRS, or if Yes, WTS Checks if Relevant RFQ 
Parameters Set; if No, Sends Rejection Message to 
Customer GUI, or if Yes, Sends Rate Request to WRS 

; - 

WRS Receives Rate Request, Checks if Instrument/Rate 
Suspended; if No, WRS Checks if Deal Size Exceeds 
Available Volume, or if Yes, WRS Checks if Relevant RFQ 
Parameters Set; if No, Sends Rejection Message to WTS for 

Customer GUI, or if Yes, WRS Checks if Deal Size 
Exceeds Available Volume; if Deal Size Does Not Exceed 
Available Volume, WRS Sends Executable Rate to WTS, or 
if Deal Size Does Exceed Available Volume, WRS Checks 

if Relevant RFQ Parameter Set; if No, Sends Rejection 
Message to WTS for Customer GUI, or if Yes, Sends RFQ 
Message to WTS 

J 

WTS Receives Executable Rate From WRS; WTS Checks if 

Deal Amount Exceeds Transaction Limit; if No, Sends 
Executable Rate to Customer GUI, or if Yes, WTS Checks 
if Relevant RFQ Parameter Set; if No, WTS Sends 
Rejection Message to Customer GUI, of if Yes, WTS 
Determines RFQ is Required 



FIG. 6 
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. WTS Receives RFQ Message From WRS or Determines RFQ is Required; Sends RFQ 
Message to Customer GUI; Sends RFQ Notification to MAI 


- S6 


i 

▼ 




Customer GUI Receives RFQ Message From WTS; Disables "Buy" Button and 
Enables "Re-Request" and "cancel" Buttons; Sets RFQ Timer 


- S7 






MAI Receives RFQ Notification From WTS; Sends RFQ Notification to Trader 

GUI 


- S8 






Trader GUI Displays RFQ Message on RFQ Message Screen 


- S9 


1 




Trader Enters Selection of RFQ From Message Screen 


- sio 


i 




Trader GUI Gets Transaction Details From WTS and Displays Transaction Details 

on Transaction Screen 


- S11 






Trader Enters Acceptance by Pressing "Accept" Bunon or Rejection by Pressing 
"Reject" Button on Transaction Screen 


- S12 


1 

T 




Trader GUI Sends Trader's Acceptance or Rejection to WTS 


- S13 


1 




WTS Sends Trader's Acceptance or Rejection to Customer GUI; Updates RFQ 
Status in WTS Transaction Database; Broadcasts Updated RFQ Status Via MAI to 
AH On-Line Category Traders 


- S14 


♦ 




Customer GUI Receives Trader's Acceptance or Rejection; if Rejection, Displays 
Refusal Message, and Enables "Re-Request" and "Cancel" Buttons; or if 
Acceptance, Displays Trader's Rate 


- S15 






Customer Sees Display of Trader's Rate; Enters Customer's Rejection of Trader's 
Rate by Pressing "Cancel" Bunon; or, if Not Timed Out, Enters Acceptance of 
Trader's Rate by Pressing "Buy" Button and Transaction is Executed 


- S16 
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Customer Telephones Sales Trader and Requests Warrants Transaction - S101 



I 



Sales Trader at Sales Trader GUI Logs in and Inputs Name and 
Password Information and Enters Warrants SE No., KV No., or Depot 
No., if Known; Alternatively, Enters Counterparty Bank Name; Presses 

"Get Price" Button 



Sales Trader GUI Sends Entered Information and Price Quote Request 

to WTS 



I 



WTS Validates Entered Information; Checks RFQ Parameters and, if 
Applicable, Triggers RFQ Process, or if not Applicable, Sends Price 

Quote Request to WRS 



WRS Checks RFQ Parameters and, if Applicable, Triggers RFQ 
Process, or if Not, Generates Two- Way Buy-Sell Price Quote; Sends 

Price Quote to WTS 



I 



WTS Sends Price Quote to Sales Trader GUI 



i 



Sales Trader GUI Displays Price Quote on Sales Trader Deal Entry 

Screen; Sets Timer 



i 



Sales Trader Receives Customer's Rejection of Price Quote on 
Telephone and Enters Rejection by Pressing "Cancel" Button; or 

Receives Customer's Acceptance and Desired Volume on Telephone 
and Enters Volume and, if Price Quote Not timed Out, Executes 

Transaction by Pressing "Buy" or "Sell" Button on Deal Entry Screen 



- S102 



- S103 



- S104 



- S105 



- SI 06 



- S107 



- SI 08 



FIG. 16 



34 



EP 1 006 471 A2 



FIG. 17 



228 



Service Provider's Datacentre 



216 

I 

First Bank's CATS-OS 




CATS-OS Transaction 
Server (WTS) 



8 




CATS-OS 
Middleware 
ITS 
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...I ■- 

Second Bank's CATS-OS 



CATS-OS Transaction 
Server (WTS) 



Rate 
Server 
(WRS) 



HandofT 
Server 
(WHO) 




Rate 
Server 
(WRS) 



Handoff 
Server 
(WHO) 





Firewall 
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220 




First Bank's Datacentre 
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Firewall 
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Second Bank's Datacentre 
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Customer Logs on and Enters Price Quote Request at Customer GUI 



- S20l 



Customer GUI Sends Price Quote Request Via Shared Communication and 

Messaging Layers Simultaneously to WTS of Each of a Plurality of l S202 
Independently Maintained and Segregated Financial Institution Trading 

Systems 



WTS of Each Financial Institution Trading System Checks RFQ Parameters 
and, if Applicable, Triggers RFQ Process, or it Not Applicable, Sends Price - S203 
Quote Request to its Corresponding WRS 



WRS of Each Financial Institution Trading System Generates and Returns 
Executable Rate Quote to its Corresponding WTS 



- S204 



WTS of Each Financial Institution Trading System Sends Rate Quote Via 
Shared Communication and Messaging Layers to Customer GUI 



- S205 



Customer GUI Receives and Displays Executable Rate Quote From WTS of 
Each Financial Trading System, Such that the Rate Quote From the WTS of 
a Particular Financial Institution's Trading System and the Identity of the 
Particular Financial Institution is Known Only to the Particular Financial 
Institution and the Customer and Unknown to Each of the Other Financial 

Institutions 



- S206 



Customer at Customer GUI Enters a Selection and Acceptance of a Rate 
Quote From the WTS of One of the Financial Institution Trading System 



- S207 



Customer GUI Sends Customer's Selection and Acceptance Via the Shared 
Communication and Messaging Layers to the WTS of the Trading System 
Which Presented the Selected Rate Quote, Such that the Selection is Known 
Only to the Particular Financial Institution and the Customer and Unknown 
to Each of the Other Financial Institutions 



WTS of the Selected Financial Institution Trading System Receives the 
Customer's Selection and Acceptance and Sends to WHO of the Selected 
Financial Institution for Processing 



- S208 



FIG. 
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- S209 
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